A type of data storage architecture according to the Background Art is an internal mirror architecture. FIG. 1 is a block diagram of a disk array 100 having an internal mirror architecture according to the Background Art. Disk array 100 includes a controller 102 and a plurality of disk drives (disks not depicted individually) configured to provide a primary logical storage device (LDEV) 104 and a secondary LDEV 106. Secondary LDEV (hereafter, S-LDEV) 106 represents a data mirror of primary LDEV (hereafter P-LDEV) 104. A pointer 105 is mapped from P-LDEV 104 to S-LDEV 106 to designate the logical flow of data from the P-LDEV 104 to S-LDEV 106. At certain times, controller 102 causes P-LDEV 104 to make data updates (using pointer 105) to S-LDEV 106.
A logical storage device, e.g., each of 104 and 106, can represent part or all of one or more disk drives, respectively, in the array thereof. P-LDEV 104 and disk controller 102 have a bidirectional connection to a control bus 108 while there typically is a uni-directional connection from bus 108 to S-LDEV 106 during normal primary to secondary volume data flow.
A source of data, e.g., application server 118, stores data on disk array 100 via sending data writes to a logical unit (LU) X 110 (hereafter, LU_X). LU_X 110 represents a mapping by controller 102 of a pointer 112 from a first port to P-LDEV 104. Application server 118 typically has read/write access to LU_X 110.
Disk array 100 can represent a node N in a storage hierarchy. A node below (or, in other words, downstream from) N in the storage hierarchy is referred to as node N+1. Node N+1 can be represent, e.g., another storage device, a data mining server, etc. Here, for the purposes of discussion, it will be assumed that node N+1 is a downstream (e.g. host computer) node 120. Downstream node 120 obtains data from disk array 100 via data reads made to a logical unit (again, LU) Y 114 (hereafter, LU_Y). LU_Y 114 represents a mapping by controller 102 of a pointer 116 from a second port to S-LDEV 106. Downstream node 120 typically has read-only access to LU_Y 114.
A drawing simplification is noted. Controller 102 generates the logical mapping that is illustrated in FIG. 1 as LU_X 110 and pointer 112, as well as LU_Y 114 and pointer 116. So, in actuality, controller 102 is interposed between application server 118 and P-LDEV 104, and between downstream node 120 and S-LDEV 106. But for simplicity of illustration, controller 102 is not drawn as part of the path that includes LU_X 110 and pointer 112, nor as a part of the path that includes LU_Y 114 and pointer 116.
After initial data copy initialization, mirrored pair 104 & 106 can assume two major states: pair; and suspend. In the pair state, controller 102 will copy new data from P-LDEV 104 to S-LDEV 106 for the purpose of maintaining S-LDEV 106 as a mirror of P-LDEV 104. Typically, such updating is done opportunistically and/or out of order (OOO), e.g., disk controller 102 will only divert its finite resources to keeping S-LDEV 106 updated when it has bandwidth to spare, and when the updating occurs then it is done by periodic copying of changed tracks based on a bitmap which does not preserve the order of writes from server 118. Hence, the data on S-LDEV 106 is inconsistent relative to the data on P-LDEV 104.
A user, e.g., an administrator of disk array 100, might desire to have consistent data on S-LDEV 106 available to downstream node 120. This can be accomplished by requesting a transition to a suspend state. In the suspend state, the data on S-LDEV 106 accurately mirrors the data in existence on P-LDEV 104 as of when the suspend command is executed. As part of a transition from the pair state to the suspend state, architecture 100 passes though a synch copy state 206. In synch copy state 206, controller 102 completes a synch copy that provides S-LDEV 106 with any incremental changes in data that might be needed based on a bitmap of changed tracks maintained for P-LDEV 104.
During the suspend state, application server 118 can write new data to P-LDEV 104, but the mirroring of those writes to S-LDEV 106 is suspended; hence, the term “suspend” implies the suspension of data updating from P-LDEV 104 to S-LDEV 106. Any writes to P-LDEV 104 during the suspend state are tracked in a changed-track bitmap. Likewise, as S-LDEV 106 is writable by downstream node 120 while in suspend state, S-LDEV 106 also keeps a changed-track bitmap.
A user might wish to obtain more current data on, e.g., S-LDEV 106 than the static (and progressively more stale as time elapses) data available on it during the suspend state. This can be accomplished by requesting a resynchronization in the form of a change back to the pair state. As part of the transition from the suspend state to the pair state, architecture 100 passes through a discard state and then through the synch state. In the discard state, arrangements are made for data to flow (subsequently at the synch state) from either P-LDEV 104 to S-LDEV 106 (a normal resynch; more common) or from 106 to 104 (a reverse resynch; less common). For a normal resynch, changes to S-LDEV 106 are discarded in favor of changes made to P-LDEV 104. For a reverse resynch, changes on P-LDEV 104 are discarded in favor of changes made to S-LDEV 106.